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A pplicants have agreed to Examiner's amendments to the apparatus claims to include a 
p ocessor to darify and more distinctly point out and claim applicant's invention, but 
not to overcame any prior art. The amendments made incorporate terms of description 
ai Ld not of limitation 



A pplicants respectfully submit that the distinction between applicants' invention and 

rt dlining was addressed in applicants' parent applications. In the excerpts below, 

a| fphcants have indicated in bold face type in brackets where the cited portions of the 

p irent specification are found in the current pending application [bold face in brackets 

f c ir current pending application ]. In the parent cases it was noted that: 

For the phrase "automated negotiations engine" support is found in the 
specification at Page 60, lines 9-20, Page 61 lines 1-18, and Page 62, lines 1-18, 
{Page 65, lines 5-18, and Page 66, lines 1-16) where the processing steps of the 
automated negotiations engine are described. On Page 62, lines 11-16 [Page 66, 
lines 9-14], for example, state: 

Whether or not a concluding document is requested, the system 
automatically displays the changes so they can be easily seen and the 
present invention also checks to see whether a state change is needed at 
Step 212-16. If a state change is needed it is initiated at step 212-20. 
Depending on the community, the participants, and the transactions 
involved, state changes could be as simple as payment authorizations sent 
electronically or as complex as multi-step processes desired by the 
participants. [Emphasis added] 

Also, as noted in the specification at page 52, lines 14-18 and Page 53, lines 1-4 
(Page 56, lines 3-12]: 

Next, in Figure 1L, network functions 207 of the present invention 
are shown. As mentioned above, most of the functions of multivariate 
negotiations engine 212 are actually implemented as part of Webserver 
software 210s . As data is sent to and from the Internet 04 by Webserver 
210W, Webserver software 210s i nterprets the TCP-IP protocol and 
transfers the contents to multivariate negotiations engine 21Zs 
Webserver and dynamic HTML functions 207-02 . In one embodiment, 
these functions cause dynamic HTML text to be created to implement and 
communicate with the other functions of the present invention* Those 
skilled in the art will appreciate that Java, Java scripting , XML, or any of 
a number of other languages could also be used for such communications. 
{Emphasis added] 
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Thus, it can be seen from these and other portions of the speoficabon, amending 
the claims to clarify that the negotiations engine is an automated negotiations 
engine has ample support in the specification as filed. It is implemented m 
computer software which is executed as part of Webserver software in the 
example referenced above. 

Support for the phrase "analyzing terms, the analysis of terms comprising 
understanding their purpose, formatting the terms according to the purpose and 
placing them into user supplied context for use by a user* is found mthe 
specification at Page 86, lines 15-19 and Page 87, lines 1-4 [Page 91, lines 16-18 

and Page 92, lines 1-61: , . ^. . ^ . , , 

For example, and still in Figure 5a, if a buyer participant 08 wishes 
to place a proposed order, the browser encrypts it at the browser's secure 
socket layer and webserver 210s decrypts the proposed order upon receipt 
at multivariate negotiations engine 02's site. Webserver 210s next analyzes 
the proposed order to understand it and formats into a request sent to 
database ftup HSrma ?77 In addition to basic read and write functions, 
database function m shown in Figure 5 a. include operations such 3? 
sparch. analyze, compare, report sort and relate (between databases.) 
Formatting can be as simple as "user = usemame" etc A request such as 
"find user^usemame, return catalog" might be sent through IP firewall 
203f . (Emphasis added] 

User supplied context, which can be defined as a number of interrelated variable 
terms or items as noted in the specification at page 44, lines 19 and 20 [Page 47, 
lines 18-19 and Page 48, line 1], for example, includes rules supplied by a 
sponsor, terms and conditions supplied by a seller, terms supplied by a buyer, 
etc., as shown in more detail below. 

An example of "user supplied context" is found in the specification at Page 65, 

lines 7 -12 [Page 69, lines 8-13J, where the user is a buyer: 

Now referring to Figure 15b, a typical proposal form for a buyer is 
shown. As seen here, the buyer identifies himself, his title, his company, 
and the company's location at lines 332-342. At lines 344-350 information 
about the buyer's designated freight forwar der is given. At line 350, 
document presentation terms are spec ified, as well as at line_352, 354, 358 
and so on. the detailed terms of the buyer's prefer ences for shipment. 
[Emphasis added] 



Another example of "User supplied context" is found in the specification at 
page 45, lines 6-9 [Page 48, lines 7-10], where the user is a sponsor 

The sponsoring standards body establishes the community, 
proposes initial standards, sets the rule s for negotiations, encourages and 
monitors negotiations, and concludes with a finally agreed upon set of 
standards, with each step of each negotiation that occurred along the way 
archived. [Emphasis added] 
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Still another example of "User supplied context" is seen in the specification at 
Page 49, lines 6-15 [Page 52, lines 11-17 and Page 53, lines 1-3], where the user is 
a seller: 

Now turning to Figure Ig, the present invention can be viewed as a 
series of interrelated processes as shown here. For a commercial 
community, there are seller processes, sponsor processes and buyer 
processes. Remote authoring 50, is a seller process which enables a 
registered seller in the community to create a seller Website within the 
community on which to include the seller's marketing and product 
information, along with pricing terms, ser vice offerings and so on,, 
Information generated or created in this remote authoring process 50 is 
automatically integrated with the community databases and listirigs. 
Promotion and brand identifying actions (such as registering the Web 
page with search engines) are taken automatically on behalf of the seller 
as well. (Emphasis added] 

Support for the phrases "recognizing any changes in the terms" and "the 
automated negotiations engine indicating any changes" is found in the 
specification at Page 62, lines 1-3 [Page 67 lines 17-18 and Page 68 line 11: 

Multivariate negotiatio ns pnftine 212 keeps track of each set of 
changes and ran display them so that the changes proposed at each step of 
the negotiations are clearly and accurately recorded. [Emphasis added] 



US Patent No. 5,692,206, to Shirley et al (Shirley) was brought to applicants' 
attention as potentially rendering obvious applicants' invention's negotiations 
engine and indication of changes as part of a negotiations process. Applicants 
respectfully disagree. Shirley describes a document generation system which 
helps a user create a document for use in a negotiation, but it does not automate 
the negotiations process. (See Col 2, lines 11-45 in which it is dear that Shirley 
describes a system of libraries of standard terms from which a user can manually 
select one or more provisions.) Shirley discloses a "negotiating database" which 
is not an automated negotiations engine but simply a file or database for holding 
"one or more corporate suggestions 442 and one or more user notes 444." Col 5, 
lines 49-51. In Col, 7, lines 14-40, it is clear that Shirley describes a system in 
which the user selects from a library of standard contract provisions those 
provisions the user wants to incorporate into his or her contract proposal. This is 
not a negotiations process, but simply a way to create a proposed contract 
document that one party might send to another by regular mail, fax, or e-mail. It 
teaches away from applicants' invention by focusing on word-processing-like 
document assembly techniques, not on negotiation processes. 

Finally, Shirley does not teach, disclose or render obvious an automated 
negotiations engine for indicating changes in the proposed terms. Instead, it 
teaches away from this as well, by teaching a redlining feature in which "the user 
creates one or more redline documents 218." Col. 7, lines 61-62. The user selects 
two text versions of a document for comparison and, as disclosed at Col. 11, lines 
46-58: 
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If, at the decision block 702, the user selects a redline function, the 
system controller 102 branches to a process block 718, At the process block 
718, the system controller 102 activates the redline unit 120. The redline 
unit 120 prompts the user to select to [sic] files to be compared. A redline 
comparison is typically done between a current document and either a 
corresponding standard document or a previous revision of the same 
document. The redline unit 120 generates a new file that specifies the 
differences between the two files selected by the user, without affecting 
the selected files. The redline unit 120 may be implemented, for example 
{sic] a redlining program such as CompareRite. (Emphasis added] 

Redlining / as described above, is a text comparison of two documents. Changes 
in the text are underlined, usually in red, or "redlined." The program that does 
the redlining does not ax&lyze the changes in any way, or prompt actions as a 
result of them. 

Applicants' invention, by contrast, during the negotiations process, provides an 
automated negotiations engine that analyzes terms by understanding their 
purpose, formats them according to their purpose, and places them in a user 
supplied context for use by a user. The automated negotiations engine also 
recognizes changes in the terms and indicates what has changed. It can also 
prompt for additional information as a result of a change. For example, if a 
shipping term such as Ex Works, has changed to Deliver Duty Free, the 
automated negotiations engine system of applicants' invention knows what 
additional information to request from the user, such as the name of the user's 
freight forwarder, and will format requests for that information. 

Support for this is found in applicants specification at Page 86, lines 15-19 and 
Page 87, lines 1-4 [Page 91, lines 16-18 and Page 92, lines 1-6], as referenced 
above, as well as in Figure 15 C-l and Figure 15 02. 

A :»plicants respectfully submit that the above clarifications apply to the present 
aj plication as well. Unlike redlining, applicants' invention analyzes terms, the analysis 
of serms comprising understanding their purpose, formatting the terms according to the 
pi rpose and placing them into user supplied context for use by a user. As shown above, 
us er supplied context refers to the fact that users of applicants' invention can supply the 
co itext for one or more negotiations. In the illustrative examples shown in the 
sp deification and the drawings, user supplied context has included, among other 
th ngs: community rules; standards; buyer's terms; seller's terms; sponsor, seller, 
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ai id buyer processes; application programming interfaces; templates; administrative 
ir formation; product information; procedures; text, image and sound files; deciding 
ej itities, and numerous other items, according to the kind of negotiation and the kinds 
oj users involved. Non-commercial users may supply very different types of user 
si pplied context as shown in the parent application at Page 61, lines 2-6 [Page 64, line 
II- and Page 65, lines 1-4], 



Ir the discussion with the Examiner, applicants were also asked to clarify the 

d: istinctions between applicants' invention and that which is claimed and disclosed in 

U ; ; Patent. No. 6,055,519 issued to Kennedy et al on April 25, 2000, entitled 

"1 ramework for Negotiation and Tracking of Sale of Goods ("Kennedy"). 



A replicants respectfully submit that Kennedy does not disclose, daim, nor tender 
ol ivious an automated negotiations system for processing negotiations. The Kennedy 
s> stem does not process negotiations, but stores data representing the current state of a 
ni gotiation, to allow the user to monitor the state of a negotiation. This is stated in the 

A ::«tract as follows: 

A computer implemented system and process are provided for negotiation and 
tracking of sale of goods. In this system ^and process, a negotiation engine (16) 
operates to store data representing a current state (18) of a negotiation between a 
seller and buyer. The ne gotiation engine (16) stores the data within a framework 
for representing aspects of the negotiation between the seller and buyer- The 
framework includes a request object, a promise object and an acceptance object 
that can store a current description of a contract The framework also includes a 
set of one or more delivery deals determined by the contract. Each delivery deal 
can have a delivery request object, a delivery promise object, and a delivery 
acceptance object that can store associated item deals and time periods for 
delivery of item deals. Each item deal can have an item request object, an item 
promise object, and an item acceptance object that can store individual sales- 
order line-items. The ne gotiation engine (16) thereby allows a user to monitor the 
current state of the negotiation . . - 
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Tliisis also dear from the following text in the description of the Kennedy patent at 

Col. 4, lines 4-17: 

Buyer 14 can have a negotiation client 22 that communicates with 
negotiation engine 16 across a network communication layer Negotiation client 
22 can comprise a software application executed by a computer system and 
allows buver 14 to query current state 18 . Negotiation client 22 can be used to 
communicate requests and acceptances from buyer 14 to seller 12, and 
negotiation engine 16 can be used to communicate promises from seller 12 to 
buyer 14. The request promise and acceptance in formation can also be 
communicated through other means such as bv fax, ph one, etc. According to the 
present invention, negotiation engine 16 provides a fr amework for maintaining 
current state 18 to reduce or eliminate any confusion about the status of the 
negotiation and relevant terms. {Emphasis added] 

Ei sentially, Kennedy stores data objects of limited types which represent a request, a 

pj omise or an acceptance. Since the data stored in the objects could have been 

cc iranunicated by fax or telephone, it is dear that Kennedy is simply storing the data, 

it processing a negotiation. The Kennedy "negotiation engine" stores these objects, 
ai id as will be seen below, uses the time stamps associated with each to determine the 
st situs of the "negotiation". 



T : us state monitoring is described at CoL 5, lines 50-57 as follows: 

In the present invention, the state that a negotiation is in can be 
determined, for example, from the relative values of four time stamps: the date 
that the most recent request was issued, the date that the most recent promise 
was offered, the date that the most recent acceptance was made, and the most 
recent date that the request was queued. If there is only a request issued date, 
then the negotiation can be identified as being in state 32. {Emphasis added]. 



K nnedy also states at Col. 4,lines 26-35: 

In the embodiment of FIG. 2, the negotiation can move through twelve 
states. There are essentially five kinds of changes that can be made to cause state 
transitions: the buyer can issue a new request (R), the seller can offer a new 
promise (P), the buyer can queue a request (Q), the buyer can accept a promise 
(A), or the buyer can delete or withdraw a request (D). AH five changes are not 
necessarily applicable to each state . In particular, the buyer can delete or 

7 
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withdraw a request until it is accepted, but once accepted, the request can no 
longer be withdrawn by the buyer. [Emphasis added) 

T >is makes it dear that the system itself is only reporting on state transitions. It is 
tr kicking what the buyer and seller have done in the past, as the description expressly 
St ates at Col. 6, lines 19-25: 

...the negotiation process can thus be tracked between buyer and seller in 
constrained environments by providing a framework for progressing through 
the state diagram of FIG. 2 while also storing the current state of and relevant 
data for the negotiation [Emphasis added] 

T. xe limitations on a buyer and seller are illustrated by the following sample, from col. 4, 
lines 48-54: 

From state 34, the buyer can do one of four things. The buyer can delete or 
withdraw the request which moves the negotiation bade to state 30. The buyer 
can issue a new request, moving the negotiation to state 36. The buyer can queue 
the existing request, moving the negotiation to state 38, and the buyer can accept 
the promise, moving the negotiation to state 40. 

Fi i rther, Kennedy does not recognise the users as negotiators or recognize one of them 
a< a deciding entity. 



In stead, Kennedy is simply monitoring and tracking the state of some very limited 

cc iitmunications between a buyer and a seller. Even while describing some of its 

a< vantages, this is made apparent at Col. 6, lines 43-50: 

The present invention provides numerous advantages over conventional 
negotiation processes. First, the exact state of the negotiation is detailed in such a 
way that automated and semi-automated decision systems (such as planning 
systems, order fulfillment systems, purchasing systems, supply chain 
management systems, etc.) can work against the alternate state transitions, and 
deal with the changes in states over time. [Emphasis added.] 

Tl is, and similar sections of the specification make it readily apparent that this is a 
m mitoring and reporting system, not a negotiations system. 

8 
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In addition, the system appears to be primarily designed for the use of planners (not 
re gotiators) for order or demand management systems in either a buyer' s or seller's 
oi ganizatjon as seen at Col. 9, lines 57-64: 

The Request, Delivery Request, and Item Request structures together 
model and provide a framework for requests from one site to another. The 
Promise. Delivery Promise, and Item Promise str uctures together model and 
provide a framework for the supplying (promisin g site's commitment back to 
the requesting site. These structures t ogether implement what is traditionally 
rallPd "Order Management" or Dema nd Management" Simplified variations of 
those structures are often called "orders." [Emphasis added] 



A % part of this, the Kennedy specification describes some specific formats and types of 
w quest, promise and acceptance objects, containing pre-defined fields for data such as 
qi lantity, due date, price, etc If a buyer and seller use these pre-defined object formats 
so id fields, the system can track their communications and feed the specific data into 
oj der management or demand management systems. Alternately, as stated above, their 
a rrrespondence by telephone or fax can be stored in these formats and thus tracked. 



T ne specification states at col. 14, lines 39-41 that The basic information provided is the 
si ate of the negotiation for each order (e.g. whether the order is Requested, Promised, or 
A .xepted)." and, at Col. 14, lines 42-52 that- 
Additional information can be provided which is termed "problems". An , 
example problem is an order whose Promise does not match the Request 
Another example is an order that is Promised but not Accepted (part of the 
"basic information" mentioned above). Another example is an order that is 
not yet promised and is planned but the planned delivery is later than 
requested. These pieces of information are critical for a human or automated 
planner to juggle capacities and modify plans in a way that optimizes 
performance of the supply chain. [Emphasis added] 
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In furtherance of the above statement, the specification describes, at Col. 14, lines 66-67 

ard Col. 15, lines 1-3: 

. . .types of problems that can be identified. It covers the meaning of each 
problem, the data used to identify the problem, and where possible the 
resolution methods bv which a human or auto mated planner could try to 
eliminate or reduce the severity of the problem. [Emphasis added] 

A n example of one of the types of problems which the invention can identify is found at 

Ci 15, lines 10-21: 

A "Request Not Harmed" problem indicates that the item request was 
issued after the item promise was offered-and-the 'delivery plan' has not been 
planned to satisfy the item request: either there is no 'delivery plan , or the 
delivery plan' is for the older item promise. This Problem will not occur if the 
delivery request has an infinite due' Date, the item request is for a zero 
"quantity , or the item promise was offered after the item request was issued (or 
last modified). To resolve this Problem , either eliminate or zero out the item 
request (unlikely), offer' a Promise and switch the 'delivery plan' to satisfy the 
promise, or create and/ or replan the 'delivery plan ' to meet the item 
request -fEmphasis added] 

A h this example, and the others show, this problem identification is done, for the most 
p irt, after the fact when the negotiation has presumably completed and primarily for 
e benefit of the planner or demand management system, not the negotiators. 



If the planner uses one of the recommended solutions to "fix" the problem, the system 
w ill update the problem data, and reflect that; as described in the specification as well, 
al Col. 18, lines 1-13: 

As any change occurs to the data of a Request, Promise, Acceptance, 
Delivery Request, Delivery Promise, Delivery Acceptance, Item Request, Item 
Promise, or Item Acceptance, the invention reanalyzes the data and updates the 
identified problems. Data changes cause some problems to be eliminated and 
potentially others to be created. The human planner can see these updates in a 
character-based user interface or a graphical user interface. The automated 
planner would see these updaft ** hy notification of which problems are 
eliminated and which (if any) are created. For this purpose, the invention has a 



in 
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database of problems and an interface to an automated p lanner which 
communicates the stream of created and destroyed problems . (Emphasis added] 



K ?nnedy does state, at Col. 18, lines 14-28 that in connection with such problems, : 

Changes can be made at any point in a negotiation, including after the 
negotiation is traditionally viewed as "complete" (Acceptance is made). 
After acceptance, the seller and buyer both have the ability to reopen 
negotiations- The seller is allowed to change the Promise to reopen 
negotiations. The buyer is allowed to change the Request to reopen 
negotiations. (The invention allows this, although some applications of the 
invention may not In a manufacturing operation, machine breakages and 
strikes really require that promises be broken- Likewise, a supplier can 
rarely be rigid with their customers 1 requests.) When such changes occur, 
request-promise-acceptance problem calculati ons can be rerun . However, a 
locking mechanism can be used to prevent request and promise data from 
changing and instead reporting a warning if any entity attempts to change 
such data. [Emphasis added.] 

It is dear both from the specification and the claims, that this identification of problem 
cc nditions is used to, as Kennedy's Claim 14 puts it "pinpoint mistakes in the 
n< ^gotiatiorL" 



K nnedy does not disclose or claim or render obvious a system for processing 

n< gotiations, but a system for monitoring state transitions amongst a set of narrowly 

di ifined objects. 



K snnedy does not recognize the users as negotiators nor does it recognize one of them 
aj= a deciding entity. It appears that one primary user of the system described in 
K :nnedy is a human or automated planner and that actual negotiators are simply being 
m :mitored by a system in which they can store data or in which data is stored about 
th i ;ir actions, which may have taken place by telephone or fax, and not through direct 
us e of the monitoring system of Kennedy (see CoL 4, lines 12-15: "The request, promise 
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ai .d acceptance information can also be communicated through other means such as by 
fa <, phone, etc"-) 

A ^plicants respectfully submit that Kennedy is not a negotiations system at all, but as 
it ^ys, a framework for a tracking or mo nitoring system for a very limited set of 
tr, knsaction types related to order and demand management for the sale of goods. 
K >nnedy does not disclose, claim, nor render obvious applicants' invention. 

A :>plicants respectfully submit that alt bases for objection and rejection have been 
o^ ercome and that Claims 2-98 are in condition for allowance- Reconsideration of all 
th e claims is requested- Allowance of Claims 2-98 at an early date is solicited. 

A :>plicants ' Attorney respectfully requests that if she can be of any further assistance in 
pi ttting all the claims in condition for allowance that she be reached by telephone at 
5( !*-653-8143 or by cellular phone at 508-308-2109 in order to discuss the application 
w th the Examiner, so that any new objections or rejections may be addressed. 

D ite: August 20, 2003 

Respectfully Submitted, 

Maureen Stretch 
Reg. No. 29,447 

C ist. No. 27,443 26 Charles Street 

Te L 508-653-8143 Natick, MA 01760 
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